* How good is the data compression I get with TCompress?
All data compression is dependent on the method used and the nature of the
input data. For best compression use the LZH algorithm -- its results should
be similar to those you would get when using Zip compression with the same
file(s). See the Introduction to Data Compression section of the Compress.hlp
help file.
* I have some files which don't get any smaller when compressed using
TCompress. Why not?
See the question above. Some files have data which is already so complex that
they won't compress significantly, or at all. If you have coLZH set as your
CompressionMethod, you should get roughly the same level of compression as
common compression utilities will give you -- sometimes better.
* Why don't "protected" Paradox tables compress well with TCompress?
When you protect a Paradox table, the entropy or "randomness" of its data
increases significantly -- so much so that all compression algorithms become
much less efficient. You'll encounter this whether you use TCompress or any
other common compression utility.
* Is there a routine or component to auto-compress entire records within a
database?
No. TCompress provides file-level compression (e.g. the entire set of
database files into a single archive) and TCDBMemo etc. provide blob-level
compression (e.g. autocompressing memo, image or binary fields in your
database). There isn't a way to compress entire database records and still
provide the kind of fast indexed random access which most databases require.
**** How To:
* Can I seek into the middle of a compressed file and decompress just part of
it?
Generally speaking, no compression method will permit this. However, it can
be "faked" in either of the following ways:
1. Decompress the entire file into a temporary TMemorystream, then use the
TStream seek and read methods to access any part of it. This is not useful if
the file is huge of course, but decompressing to a temporary TFilestream
instead might be viable for some situations.
2. Instead of compressing it as a single file, compress it as a series of
"chunks" or file segments, all stored in a multi-file archive (each chunk can
be given a name in the archive which is its number, e.g. "1", "2" etc). With
this approach you can randomly select any chunk and decompress it
individually. For performance-critical applications, also see the question
below on speeding up access to multi-file archives.
* Does TCompress handle updates and deletions from an archive nicely, or does
it leave "holes"?
If the standard CompressFile(s)/DeleteFiles/ExpandFile(s) methods are used,
archives are rewritten to eliminate holes and remove old files. You can
bypass or delay this archive rewriting process if you want by using routines
like CompressStreamToArchive.
* How do I use TCompress/TCDBMemo etc. if I have a Data Module in my
project?
Put the TCompress object on your Data Module with your tables. Any CDBMemo
etc. objects should still be on the appropriate form(s) of course.
* How can I speed up access to files in an archive?
For small archives, this is hardly necessary --- finding and decompressing
any file is generally very fast. But if your archive gets very large, the
sequential search needed to find a given file to decompress it can be a time-
waster. A solution to this is to use ScanCompressedFile once when you
first access your archive (as the Compdemo example application does). This
process also creates a TCompressedFileInfo object for each file containing
its position in the archive. With that information, you can open the archive
as a TFileStream, seek directly to the appropriate place and use the DoExpand
method to expand just that file. Time savings on large archives by using this
method can be very significant indeed.
* How can I compress a string in memory?
Use the CompressString and ExpandString methods (new in V3.5).
* How can I read string data and compress it into a blob field?
The simplest possible way is to use CompressString, then store that in the blob as binary data. However, this means you'll have to take care of the reading and expansion process yourself as well.
A better way might be to use the visual CDBMemo component and simply use its LoadFromFile method to load the strings. If its compression properties are correctly set, it will auto-compress the data when the record is posted.
If you want to do it non-visually (e.g. on a data module), do as follows:
a) Create a non-visual TCBlobfield component on-the-fly and point it at your existing memo field (see BLOBMAIN.PAS for an example of this).
b) Set its CompressSource and CompressionMethod properties appropriately
c) Then step through each record of the table doing this:
edit;
OurBlobField.LoadFromFile(yourExternalFilename);
post; { write back, forcing it to compress as it is written }
Note that other handy assignment methods are available, including LoadFromStrings. If you want to compress existing uncompressed data in the memo, just assign the field to itself so that it is marked for updating, e.g. OurBlobField.asString := OurBlobField.AsString (good in Delphi 2 and 3 -- in Delphi 1 you'll have to SaveToStrings into a TStringList, then LoadFromStrings back again).
**** Problems (also see the Troubleshooting section of Compress.hlp):
* I compressed a file using TCompress, but I can't seem to decompress it. Why
not?
There are two likely reasons:
1. You have your parameters round the wrong way when calling the ExpandFile
method. Sensible parameter naming will help you avoid this, e.g.
ExpandFile(StoredFilename, ArchiveFilename).
2. You are not specifying the correct StoredFileName. It should match the
filepath which is stored in the archive -- which can be double-checked by
using the Compdemo program. Review the Compress.hlp help sections on
TargetPath and "Filename Handling in Compressed Archives" to see some
examples of how to control what filenames and paths are stored in the
archive.
* I compressed something into a stream, but I can't seem to expand it.
Why not?
Don't forget to either close and reopen the stream or (more commonly)
seek back to the beginning of the stream before trying to expand from it!
* How do I eliminate the registration popup message? Is any other
functionality affected in an unregistered copy of TCompress?
When you register TCompress, you will be given values to set into the RegName
and RegNumber properties of your TCompress components. If you set these
exactly as provided to you, they will eliminate the popup. Apart from the
popup message, unregistered copies of TCompress behave exactly the same as
registered ones.
* My application says "Requires BDE" when I run it on another machine. Does
TCompress require the Borland Database Engine?
No. If you are not using the database blob compression components (CDBMemo etc),
then you don't need the BDE. Just be sure that your project units
don't have any unintentional references to "DB" or "DBTables" etc. in their
Uses clauses. If you are a Delphi 3.0 user, make sure you have the comp35.dpk
package installed, not the compdb35.dpk package, as the latter "requires"
VCLDB30.
* Do you have any demo programs written specifically for C++ Builder, or are
they all Pascal?
At this point, all the demonstrations are in Delphi. Visit our Web site at
http://www.spis.co.nz/compress.htm from time to time to check for C++
versions of the demonstrations.
* What should I do if I get an "Out of Memory" message using TCompress?
This is rare and will only arise if physical or swapfile memory is limited --
free up more disk space on your Windows swap drive.
* My application's memory use seems to increase every time I decompress
files. Why?
If you are using the ScanCompressedFile or ScanCompressedStream methods,
see the notes in their section of Compress.hlp about the TCompressedFileInfo
information and the FreeFileList method, which will allow you to eliminate
memory loss.
</pre>
<P>Return to <A HREF="http://www.spis.co.nz/compress.htm">TCompress</A>
